2008 24.05.(Sa) 21:03:48  <txwikinger> Was ist Bugtriage?
2008 24.05.(Sa) 21:04:04  <txwikinger> Das Wort triage ist von dem französischen Wort trier abgeleitet, welches die Bedeutungen Ordnen, Aussortieren hat.
2008 24.05.(Sa) 21:04:20  <txwikinger> Normalerweise ist es in der Medizin benutzt. Dies trifft im Besonderen zu in der Notaufnahme und in Katastrophensituationen.
2008 24.05.(Sa) 21:04:35  <txwikinger> Es geht darum limitierte Einsatzmittel und Arbeitskräfte klug einzusetzen.
2008 24.05.(Sa) 21:04:35  <txwikinger> Also gibt es zum Beispiel Notfälle die warten können, während andere unbedingt schnelle Behandlung benötigen.
2008 24.05.(Sa) 21:04:55  <txwikinger> Diese Analogie besteht auch in etwas anderen Umfang mit Fehlerbeschreibungen. Fehlerbeschreibungen haben verschiedene Wichtigkeit und Dringlichkeit.
2008 24.05.(Sa) 21:05:20  <txwikinger> Die Arbeitskräfte die an den Fehlerbeschreibungen arbeiten sind beschränkt. Im Besonderen gibt es keine unbegrenzte Zahl von Entwicklern, die Fehlerberichte bearbeiten können.
2008 24.05.(Sa) 21:05:44  <txwikinger> Wenn Fehlerberichte in Launchpad erstellt werden, werden sie normalerweise von Nichtentwicklern angesehen und auf Vollständigkeit geprüft.
2008 24.05.(Sa) 21:06:14  <txwikinger> Sollte Information fehlen, die notwendig ist, kann diese(r) Bugtriager nach der Information nachfragen.
2008 24.05.(Sa) 21:06:27  <txwikinger> Ausserdem werden die Fehlerberichte sortiert und priorisiert.
2008 24.05.(Sa) 21:06:46  <txwikinger>  Dies erlaubt das der richtige Entwickler sich den Bericht anschaut, und wichtige Probleme zuerst angesehen werden.
2008 24.05.(Sa) 21:07:07  <txwikinger> In gewisser Weise sind diejenigen, die Bugtriage machen sowas wie Vermittler.
2008 24.05.(Sa) 21:07:29  <txwikinger> Bugtriager arbeiten als Zwischenglied zwischen denjenigen die der Fehler berichtet und den Entwicklern.
2008 24.05.(Sa) 21:07:51  <txwikinger> Es wird versucht soviel wie möglich Information von den Benutzern zu erhalten und sie ein wenig zu beraten wie man diese Information aus dem Computer rausholt.
2008 24.05.(Sa) 21:08:19  <txwikinger> Auf der anderen Seite besteht eine Kommunikation zu den Entwicklern von Kubuntu oder den Entwicklern der Softwareprojekten die Teil von Kubuntu sind, also zum Beispiel KDE, Debian und anderen.
2008 24.05.(Sa) 21:08:40  <txwikinger> Da es sich also im Grossen und Ganzen um Kommunikation mit Personen handelt, ist es wichtig das Geduld und Menschlichkeit mitgebracht wird.
2008 24.05.(Sa) 21:08:55  <txwikinger> Benutzer und Entwickler haben oftmals verschiedene Interessen.
2008 24.05.(Sa) 21:09:19  <txwikinger> Es geht also darum Streitigkeiten zu verhindern und zu versuchen die Interessen beider Seiten gerecht zu werden, und vor allem dem CoC zu folgen (https://launchpad.net/codeofconduct/1.0.1)
2008 24.05.(Sa) 21:10:04  <txwikinger> Soweit alles klar?
2008 24.05.(Sa) 21:11:31  <txwikinger> ok.. dann mal weiter mit den technischen EInzelheiten des Bug-Triage Prozess
2008 24.05.(Sa) 21:11:35  <txwikinger> Bugtriage findet im Launchpad https://bugs.launchpad.net/ statt. Um alle Funktionen ausführen zu können, muss man ein Benutzerkonto in Launchpad haben.
2008 24.05.(Sa) 21:11:36  <-- juliux (n=juliux@ubuntu/member/juliux) hat das IRC verlassen (Remote closed the connection)
2008 24.05.(Sa) 21:11:49  <txwikinger> Es gibt verschiede Aufgaben im Bereich der Bugtriage
2008 24.05.(Sa) 21:12:07  <txwikinger> 1) Fehlerberichte verbessern:
2008 24.05.(Sa) 21:12:24  <txwikinger> Fehlerberichte werden oftmals von Benutzern erstellt, die den Prozess nicht vollständig verstehen.
2008 24.05.(Sa) 21:12:41  <txwikinger> Auf der anderen Seite ist es wichtig dass die Informationen in Fehlerberichten einfach zu finden und zu verstehen sind.
2008 24.05.(Sa) 21:13:14  <txwikinger> Deshalb ist es oft wichtig die Fehlerbeschreibungen u verbessern, sodass sie Sinn machen.
2008 24.05.(Sa) 21:13:29  <txwikinger> Deshalb ist es oft wichtig die Fehlerbeschreibungen zu verbessern, sodass sie Sinn machen.
2008 24.05.(Sa) 21:13:48  <txwikinger> Manchmal werden Fehlerberichte auch in einer anderen Sprache als Englisch geschrieben sind.
2008 24.05.(Sa) 21:14:11  <txwikinger> Da unsere gemeinsame Sprache in Kubuntu Englisch ist, müssen solche Fehlerberichte dann übersetzt werden.
2008 24.05.(Sa) 21:14:34  <txwikinger> Es kann auch sehr hilfreich sein, dass wichtige Informationen zu der Fehlerbeschreibung am Anfang des Berichtes hinzhgefügt werden.
2008 24.05.(Sa) 21:14:57  <txwikinger> Die Beschreibung wird im Normalfall immer als erstes gelesen.
2008 24.05.(Sa) 21:15:21  <txwikinger> 2) Sammeln von zusätzlichen Informationen
2008 24.05.(Sa) 21:16:38  <txwikinger> Das Sammeln von zusätzlichen Informationen ist oft notwendig um einen Fehler zu repoduzieren und/oder den Fehlerbericht zu triagen.
2008 24.05.(Sa) 21:16:54  <txwikinger> Meiner Meinung nach ist dies die wichtigste Aufgabe in der Bug-Triage.
2008 24.05.(Sa) 21:17:07  <txwikinger> Im Idealfall erlaubt eine Beschreibung eines Fehlerberichtes, dass eine beliebige Person sofort den Fehler reproduzieren kann.
2008 24.05.(Sa) 21:17:39  <txwikinger> Dies ist nicht immer möglich, aber ein gutes Ziel.
2008 24.05.(Sa) 21:17:52  <txwikinger> Es ist eine gute Arbeitsweise zu versuchen, ob die Beschreibung des Fehlers ausreicht den Fehler zu reproduzieren, oder zu sehen ob dies überhaupt möglich ist.
2008 24.05.(Sa) 21:18:07  <txwikinger> Falls notwendig, sollte fehlende Informationen hinzugefügt werden.
2008 24.05.(Sa) 21:18:19  <txwikinger> (Beispiel: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/102979)
2008 24.05.(Sa) 21:18:23  <kubine> Launchpad bug 102979 in ubiquity "[kde-ui] next button does not respond to keyboard" [Low,Confirmed]
2008 24.05.(Sa) 21:19:02  <txwikinger> Beim Anschauen von https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/102979/comments/2 sieht man das ich der Beschreibung gefolgt bin, und einen Weg gefunden habe das Problem zu umgehen.
2008 24.05.(Sa) 21:19:18  <txwikinger> Ich habe dann diese Information Der Fehlerbeschreibung am Anfang hinzugefügt.
2008 24.05.(Sa) 21:20:03  <txwikinger> Ich habe auch festgestellt das dieses Problem jederzeit reproduziert werden kann.
2008 24.05.(Sa) 21:20:21  <txwikinger> Oftmals beinhaltet diese Aufgabe de richtigen Fragen zu stellen, sodass der Fehlerberichter bessere Informationen geben kann.
2008 24.05.(Sa) 21:21:04  <txwikinger> Man kann sich auch die ursprüngliche Fehlerbeschreibung anschauen wenn man auf den entsprechenden Link klickt
2008 24.05.(Sa) 21:21:21  <txwikinger> Fragen dazu?
2008 24.05.(Sa) 21:22:46  <txwikinger> Noch jemand hier?
2008 24.05.(Sa) 21:23:50  <nemphis> txwikinger: ich war gerade abgelenkt
2008 24.05.(Sa) 21:23:54  <neversfelde> ja klar
2008 24.05.(Sa) 21:23:55  <PTS> Klar
2008 24.05.(Sa) 21:23:57  <nemphis> danke für deinen vortrag
2008 24.05.(Sa) 21:24:02  <txwikinger> :D
2008 24.05.(Sa) 21:24:05  <nemphis> :)
2008 24.05.(Sa) 21:24:06  <txwikinger> pk wieter
2008 24.05.(Sa) 21:24:11  <txwikinger> ok weiter
2008 24.05.(Sa) 21:24:13  <txwikinger> 3) Sortieren
2008 24.05.(Sa) 21:24:22  <txwikinger> 3a) Den Fehlerbericht dem richtigen Softwarepaket zuordnen.
2008 24.05.(Sa) 21:24:32  <txwikinger> Es ist wichtig einen Fehlerbericht dem richtigen Paket zuzuordnen.
2008 24.05.(Sa) 21:24:47  <txwikinger> Dadurch werden die richtigen Leute über den Bericht informiert. Es gibt eine guten Hinweise wie man das richtige Paket findet:
2008 24.05.(Sa) 21:24:59  <txwikinger> https://wiki.ubuntu.com/Bugs/FindRightPackage
2008 24.05.(Sa) 21:25:13  <txwikinger> Dies ist natürlich nicht immer eindeutig
2008 24.05.(Sa) 21:25:52  <txwikinger> Machmal wenn es um Interaktionen zwischen mehreren Paketen geht, kann mann mehrere Pakete zuordnen
2008 24.05.(Sa) 21:26:28  <txwikinger> Später im Prozess werden dann die Stati für die verschiedenen Pakete dann entsprechend gesetzt
2008 24.05.(Sa) 21:26:36  <txwikinger> 3b) Den richtigen Status setzen
2008 24.05.(Sa) 21:26:50  <txwikinger> https://wiki.ubuntu.com/Bugs/CommonTasks#head-6e435bd3f0413458778d4688ea2f4983e90e6ab4 gibt einen Überblick über die möglichen Stati die ein Fehlerbericht annehmen kann.
2008 24.05.(Sa) 21:27:18  <txwikinger> Für die Bug-Triage sind im wesentlichen die Stati New, Incomplete, Confirmed/Triaged and Invalid wichtig.
2008 24.05.(Sa) 21:27:45  <txwikinger> Jeder Fehlerbericht startet mit dem Status New.
2008 24.05.(Sa) 21:28:05  <txwikinger> Sobald jemand mitder Bug-Triage beginnt, und Informationen fehlen, die noch gesammelt werden sollten, wird der Status of Incomplete gesetzt bis alle notwendigen Informationen vorhanden sind
2008 24.05.(Sa) 21:28:32  <txwikinger> Wenn alle Informationen hinzugefügt sind und der Fehler kann im Idealfall reproduziert werden, dann kann der Fehlerbericht auf den Status Confirmed gesetzt werden.
2008 24.05.(Sa) 21:28:39  <nemphis> !
2008 24.05.(Sa) 21:28:47  <txwikinger> nemphis:
2008 24.05.(Sa) 21:29:06  <nemphis> Für fehler mit Status Incomplete gibts ja eine bestimmte zeitliche Frist.
2008 24.05.(Sa) 21:29:28  <nemphis> Nach Ablauf dieser Frist: Wird der Fehlerbericht wieder auf new gesetzt oder auf invalid?
2008 24.05.(Sa) 21:29:32  <nemphis> #
2008 24.05.(Sa) 21:29:55  <txwikinger> Meinst Du was automatisch passiert?
2008 24.05.(Sa) 21:30:20  <nemphis> ja
2008 24.05.(Sa) 21:30:26  <txwikinger> Automatisch wird ein "expired" flag gesetzt
2008 24.05.(Sa) 21:30:39  <txwikinger> Also bleibt der Status auf incomplete
2008 24.05.(Sa) 21:30:52  <nemphis> ok
2008 24.05.(Sa) 21:31:19  <\sh> nemphis: du meinst den LP janitor?
2008 24.05.(Sa) 21:31:37  <nemphis> LP janitor?
2008 24.05.(Sa) 21:31:37  <txwikinger> Allerdings ist dies von der letzten Aktion
2008 24.05.(Sa) 21:32:12  <txwikinger> Das hilft also eher Fehlerberichte zu finden die lange nicht beachtet wurden un auf incomplete stehe
2008 24.05.(Sa) 21:32:22  <txwikinger> Oder liege ich da falsch \sh
2008 24.05.(Sa) 21:32:52  <\sh> LP janitor ist ein cron process der bugreports und andere dinge ueberprueft...wenn bestimmte zeiten von bug reports verstrichen sind, ohne dass der bug report angetastet worden ist, werden diese expired und ggf. in eine andere tabelle verschoben und sind nicht mehr wichtig..
2008 24.05.(Sa) 21:33:19  <\sh> aber dieser prozess ist derzeit haeufig aenderungen ausgesetzt von daher gibt es keine klare aussage ueber die wahre arbeitsweise...
2008 24.05.(Sa) 21:33:43  <\sh> launchpad ist manchmal wie orakeln...man sagt was, und evtl. stimmts, oder es hat sich schon geaendert, als man das sagte ;)
2008 24.05.(Sa) 21:33:57  <nemphis> :)
2008 24.05.(Sa) 21:34:25  <txwikinger> Ok.. zurück zum Status
2008 24.05.(Sa) 21:34:27  <txwikinger> Wenn alle Informationen hinzugefügt sind und der Fehler kann im Idealfall reproduziert werden, dann kann der Fehlerbericht auf den Status Confirmed gesetzt werden.
2008 24.05.(Sa) 21:34:40  <txwikinger> Offizielle Bug-Triager (also Mitglieder im Bugcontrol Team) können hier auch den Status Triaged setzen.
2008 24.05.(Sa) 21:34:55  <txwikinger> Dies gibt den Entwicklern die Information, dass ein offizieller Bug-Triager den Fehlerbericht bearbeitet hat.
2008 24.05.(Sa) 21:35:19  <txwikinger> Einige Fehlerberichte werden bei näherer Betrachtung als keine Fehler erkannt.
2008 24.05.(Sa) 21:35:36  <txwikinger> Dies geschieht entweder, weill es nicht möglich ist, die notwendigen Informationen zu sammeln um den Fehler zu bearbeiten (zum Beipiel weil der Berichter trotzdem unvollständigen Bericht sich nicht meldet oder die Fragen nicht beantworten kann, und auch niemand anderes den Fehler reproduzieren kann).
2008 24.05.(Sa) 21:36:04  <txwikinger> In diesem Fall wird der Status des Fehlerberichtes auf Invalid gesetzt.
2008 24.05.(Sa) 21:36:27  <txwikinger> Es ist wichtig immer zu Bedenken das Statusänderungen Konzequenzen haben.
2008 24.05.(Sa) 21:36:50  <txwikinger> Wir wollen keine Fehlerberichte unnötigerweise auf Invalid setzen, nur weil die notwendigen Nachforschungen nicht gemacht wenden.
2008 24.05.(Sa) 21:37:11  <txwikinger> Ein Fehlerbericht beinhaltet vielleicht wichtige Informationen die dazu führen einen Fehler zu korrigieren, selbst wenn dies nicht von dem Bug-Triager erkannt wird.
2008 24.05.(Sa) 21:37:34  <txwikinger> Deshalb machen wir uns es nicht leicht Fehlerberichte zu schliessen.
2008 24.05.(Sa) 21:37:56  <txwikinger> Wir wollen immer sicherstellen, dass der Fehlerbericht alle notwendigen Informationen enthält bevor wir ihn in den nächsten Status bringen.
2008 24.05.(Sa) 21:38:13  <txwikinger> Fragen zu den Stati?
2008 24.05.(Sa) 21:38:44  <txwikinger> 4) Duplikate
2008 24.05.(Sa) 21:39:01  <txwikinger> Es wird immer angeregt, dass man erst schaut ob ein Fehler schon in einem Fehlerbericht beschrieben ist, bevor ein Fehlerbericht geschrieben wird.
2008 24.05.(Sa) 21:39:20  <txwikinger> Trotzdem gibt es oft mehrere Fehlerberichte für den gleichen Fehler.
2008 24.05.(Sa) 21:39:36  <txwikinger> Deshalb ist es wichtig, das Bug-Triager bei einem neuen Fehlerbericht nachforschen, ob der beschriebene Fehler schon in einem anderen Bericht beschrieben ist.
2008 24.05.(Sa) 21:39:51  <txwikinger> Falls dies der Fall ist, sollte einer der Berichte als Duplikat des anderen gekennzeichnet werden.
2008 24.05.(Sa) 21:40:09  <txwikinger> (Mehr hierzu auf der Webseite https://wiki.ubuntu.com/Bugs/CommonTasks#head-170e00a7154fcfc87f0fc50f65bba9cff7ab27fe)
2008 24.05.(Sa) 21:40:50  <txwikinger> 5) Upstream Fehlerberichte:
2008 24.05.(Sa) 21:41:02  <txwikinger> Es ist wichtig, dass die Entwickler, die wirklich an einem bestimmten Softwarepaket arbeiten von den Fehlern erfahren.
2008 24.05.(Sa) 21:41:23  <txwikinger> Wir arbeiten eng zusammen mit den Entwicklern von den unterliegenden Distros (wie zum Beispiel Debian) sowie den ursprünglichen Softwarepaketen.
2008 24.05.(Sa) 21:41:38  <txwikinger> Dies ist im gemeinsamen Interesse von uns allen. Für Kubuntu KDE ist dies insbesondere wichtig.
2008 24.05.(Sa) 21:41:53  <txwikinger> Hier ist ein Beispiel https://bugs.launchpad.net/kdebase/+bug/96151
2008 24.05.(Sa) 21:41:55  <kubine> Launchpad bug 96151 in kdebase "kcmclock does not change to correct location" [Low,Confirmed]
2008 24.05.(Sa) 21:42:23  <txwikinger> In diesen Fällen ist es wichtig nachzuforschen, ob der Fehler schon im KDE-Bugtracker existiert.
2008 24.05.(Sa) 21:42:40  <txwikinger> Wenn ja, sollte dieser Bericht in Launchpad mit dem Launchpad-Bericht verlinkt werden.
2008 24.05.(Sa) 21:43:29  <txwikinger> Das geschieht unter dem Link: "Also affects Project" für KDE oder andere Softwareprojekte
2008 24.05.(Sa) 21:44:06  <txwikinger> für Debian oder andere Distros wird der Link "Also affects distribution" benutzt
2008 24.05.(Sa) 21:44:24  <txwikinger> Ansonsten sollte der Launchpad-Bericht im KDE-tracker erzeugt werden, und dann verlinkt werden.
2008 24.05.(Sa) 21:44:41  <txwikinger> Hier sind Anweisungen wie dies zu tuen ist: https://wiki.ubuntu.com/Bugs/HowToTriage#head-ab0eb9d7731fa877b5fc866eedc4c312dab50ee7
2008 24.05.(Sa) 21:44:53  <txwikinger> Dies erlaubt Lauchpad den Fehlerbericht im KDE-Bugtracker zu überwachen und jede Statusänderung in Launchpad anzuzeigen.
2008 24.05.(Sa) 21:45:19  <txwikinger> 6) Standardantworten
2008 24.05.(Sa) 21:45:30  <txwikinger> Es hilft oftmals sehr Standardantworten in Fehlerberichten zu verwenden.
2008 24.05.(Sa) 21:45:53  <txwikinger> Dies erlaubt es höflich zu bleiben und eine gute Atmosphäre zu erhalten.
2008 24.05.(Sa) 21:46:02  <txwikinger> Hier gibt es eine Menge Standardantworten: https://wiki.ubuntu.com/Bugs/Responses
2008 24.05.(Sa) 21:46:15  <txwikinger> Im Besonderen ist die Antwort https://wiki.ubuntu.com/Bugs/Responses#head-6ee6466fdaac8c81274185f0316afd794d2ee0b6 interessant.
2008 24.05.(Sa) 21:46:27  <txwikinger> Sie kann benutzt werden, wenn ein Fehlerbericht nicht vollständig ist, aber der Berichter nicht auf Fragen nach mehr Informationen innerhalb eines Monats antwortet.
2008 24.05.(Sa) 21:47:01  <txwikinger> 7) Fragen
2008 24.05.(Sa) 21:47:16  <txwikinger> Fragen, zum Beispiel wie man bestimmte Programme benutzt sollten nicht im Bugtracker gefragt werden, sondern im Antworttracker.
2008 24.05.(Sa) 21:47:34  <txwikinger> Machmal stellt es sich heraus, dass ein Fehlerbericht wirklich eine Frage eines Benutzers ist, oder eher Hilfe für den Benutzer benötigt anstatt eine Korrektur eines Fehlers.
2008 24.05.(Sa) 21:47:53  <txwikinger> Die Berichter sollten dann höflich darauf hingewiesen werden den Answertracker in Launchpad zu benutzen.
2008 24.05.(Sa) 21:48:13  <txwikinger> Dort helfen erfahrene Helfer Probleme auseinanderzunehmen, und die wahren Fehler dann in Fehlerberichte zu bearbeiten.
2008 24.05.(Sa) 21:48:31  <txwikinger> Diese können sehr einfach von den Fragen verlinkt werden.
2008 24.05.(Sa) 21:48:41  <txwikinger> Der Answertracker ist hier: https://answers.launchpad.net/ubuntu/
2008 24.05.(Sa) 21:49:02  <txwikinger> 8) Bug-Triage Tage
2008 24.05.(Sa) 21:49:13  <txwikinger> Wir haben oftmals Bug-Triage Tage.
2008 24.05.(Sa) 21:49:32  <txwikinger> An diesen Tagen konzentrieren wir uns auf eine bestimmte Klasse von Fehlerberichten.
2008 24.05.(Sa) 21:49:53  <txwikinger> Information hierüber kann man hier finden: https://wiki.ubuntu.com/UbuntuBugDay
2008 24.05.(Sa) 21:50:15  <txwikinger> 9) IRC-Kanäle
2008 24.05.(Sa) 21:50:28  <txwikinger> Es gibt auch IRC-Kanäle die interessant sind: #kubuntu-de-bugs und #ubuntu-bugs
2008 24.05.(Sa) 21:50:51  <txwikinger> 10) Five-a-day Team
2008 24.05.(Sa) 21:51:10  <txwikinger> Wir haben ein Kubuntu-de.org 5-a-day Team
2008 24.05.(Sa) 21:51:54  <txwikinger> Natürlich ist jeder eingeladen unserm Team beizutreten und zu helfen Fehlerberichte regelmässig zu bearbeiten
2008 24.05.(Sa) 21:52:30  <txwikinger> Damit soll geholfen werden, dass die Anzahl von offenen und vorallem unbearbeiteten Fehlerberichten nicht laufend steigt
2008 24.05.(Sa) 21:52:44  <txwikinger> 11) Zusammenfassung
2008 24.05.(Sa) 21:53:09  <txwikinger> Es ist immer wichtig sich daran zu erinnern, dass wir in einem Team arbeiten.
2008 24.05.(Sa) 21:53:37  <txwikinger> Deshalb helfen wir uns auch gegenseitig. Es ist immer gut Fragen zu stellen, wenn man nicht mehr weiterweiss.
2008 24.05.(Sa) 21:53:39  <txwikinger> Auch für sehr erfahrene Leute ist es machmal schwierig, und eine zweite Meinung kann oftmals helfen.
2008 24.05.(Sa) 21:53:51  <txwikinger> Falls Ihr nicht weiterwisst, kommt in die IRC-Kanäle und fragt einfach.
2008 24.05.(Sa) 21:54:02  <txwikinger> Weitere interessante Informationen gibt es auf den folgenden Webseiten
2008 24.05.(Sa) 21:54:03  <-- Glaubenskrieger (n=conv@i577AA871.versanet.de) hat das IRC verlassen ("Konversation terminated!")
2008 24.05.(Sa) 21:54:18  <txwikinger> https://wiki.ubuntu.com/HelpingWithBugs
2008 24.05.(Sa) 21:54:18  <txwikinger> https://wiki.ubuntu.com/BugSquad/KnowledgeBase
2008 24.05.(Sa) 21:54:18  <txwikinger> https://wiki.ubuntu.com/DebuggingProcedures
2008 24.05.(Sa) 21:54:39  <txwikinger> Hier ein paar gute Bugfilter:
2008 24.05.(Sa) 21:54:52  <txwikinger> Kubuntu filters:
2008 24.05.(Sa) 21:55:10  <txwikinger> Liste der Kubuntu Fehlerberichte:
2008 24.05.(Sa) 21:55:20  <txwikinger> https://launchpad.net/~kubuntu-team/+packagebugs
2008 24.05.(Sa) 21:55:48  <txwikinger> Untriaged Fehlerberichte für Kubuntu
2008 24.05.(Sa) 21:56:01  <txwikinger> https://edge.launchpad.net/ubuntu/+bugs?field.searchtext=kdebase+%7C+kdeutils+%7C+kdelibs+%7C+kdepim+%7C+kde-guidance+%7C+kubuntu-meta+%7C+adept+%7C+kaffeine+%7C+knetworkmanager&orderby=datecreated&search=Search&field.status%3Alist=New&field.importance%3Alist=Undecided&field.importance%3Alist=Medium&assignee_option=any&field.assignee=&field.owner=&field.component-empty-marker=1&field.status_upstream=&field.status_upstream-empty-marker=1&
2008 24.05.(Sa) 21:56:01  <txwikinger> field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.tag=&field.has_no_package.used=
2008 24.05.(Sa) 21:56:20  <txwikinger> Vorsicht die zwei Zeilen müssen zusammen
2008 24.05.(Sa) 21:56:28  <txwikinger> Und da Fehlen auch die KDE4 Pakete
2008 24.05.(Sa) 21:56:48  <txwikinger> Neue Fehlerberichte und Fehlerberichte ohne Paket:
2008 24.05.(Sa) 21:56:56  <txwikinger> https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-datecreated&search=Search&field.status%3Alist=New&field.assignee=&field.owner=&field.omit_dupes=on&field.has_patch=&field.has_no_package=on
2008 24.05.(Sa) 21:57:39  <txwikinger> Ok.. ich hoffe dies gibt ein paar Anregungen und Interesse bein Bug-Triage mitzuhelfen